Migrate docker-ci-tools workflow to Github Actions #4454
Conversation
carles-grafana
force-pushed
the
drone-migrate-ci-tools
branch
from
b13e82f to
c1f3cb9
Compare
carles-grafana
force-pushed
the
drone-migrate-ci-tools
branch
from
c1f3cb9 to
f8cea50
Compare
carles-grafana
changed the title
carles-grafana
requested review from
joe-elliott,
mdisibio,
mapno,
yvrhdn,
zalegrala,
electron0zero,
ie-pham,
stoewer and
javiermolinar
as code owners
| - name: Login to DockerHub | ||
| uses: grafana/shared-workflows/actions/[email protected] | ||
|
|
||
| - name: docker-build-and-push |
There was a problem hiding this comment.
have you tried this action?
docker/build-push-action@v6
There was a problem hiding this comment.
I had seen that but I prefer to do it this way because it is more explicit and we can build each platform natively, while the other action relies on QEMU which is probably slower.
There was a problem hiding this comment.
I'm not opposed to it but other teams are using it:
I think it simplifies the process
There was a problem hiding this comment.
I say we review this once we have migrated everything, I'm sure there's room for optimization in our CI but I don't want to change things too much during the migration to make sure I don't break any process.
| docker build -f tools/Dockerfile -t $IMAGE_NAME:$TAG_ARCH . | ||
| docker push $IMAGE_NAME:$TAG_ARCH | ||
|
|
||
| manifest: |
There was a problem hiding this comment.
I think this is not needed since we are not pushing a multi-architecture image yet
There was a problem hiding this comment.
And it can be achieved as well with docker build-push-action
There was a problem hiding this comment.
In Drone we do something very similar to what I'm doing here, that is, build each platform natively and then create a multi-platform manifest -- only that in Drone we use some opaque plugins.
To clarify, this workflow is a combination of these Drone pipelines:
What this PR does:
Migrate the docker-ci-tools pipeline from Drone to Github Actions.
This includes building the Docker images, pushing them and creating the final manifest.
I've tested this in a branch of the main repo: https://github.com/grafana/tempo/actions/runs/12352580265/job/34469919545
Once merged, I'll test it by updating tools/go.mod and verifying that the produced image works.
Then we can delete the pipeline from Drone.
One change I've made from the original, to make it more efficient, is to trigger the workflow only when the tools directory changes, instead of on every commit.
Checklist
CHANGELOG.mdupdated - the order of entries should be[CHANGE],[FEATURE],[ENHANCEMENT],[BUGFIX]